As known in the field of computer networking, a visibility network (sometimes referred to as a visibility fabric) is a type of network that facilitates the monitoring and analysis of traffic flowing through another network (referred to herein as a “core” network). The purposes of deploying a visibility network are varied and can include management/optimization of the core network, security monitoring of the core network, business intelligence/reporting, compliance validation, and so on.
FIG. 1 depicts an example visibility network 100 according to an embodiment. As shown, visibility network 100 includes a number of taps 102 that are deployed within a core network 104. Taps 102 are configured to replicate data and control traffic that is exchanged between network elements in core network 104 and forward the replicated traffic to a packet broker 106 (note that, in addition to or in lieu of taps 102, one or more routers or switches in core network 104 can be tasked to replicate and forward data/control traffic to packet broker 106 using their respective SPAN or mirror functions). Packet broker 106 can perform various packet processing functions on the traffic received from taps 102, such as removing protocol headers, filtering/classifying packets based on configured rules, and so on. Packet broker 106 can then transmit the processed traffic to a number of analytic probes/tools 108, which can carry out various types of calculations and analyses on the traffic in accordance with the business goals/purposes of visibility network 100 (e.g., calculation of key performance indicators (KPIs), detection of security threats/attacks in core network 104, generation of reports, etc.).
Generally speaking, existing visibility network implementations use dedicated networking hardware (e.g., hardware comprising custom application-specific integrated circuits (ASICs) and/or field-programmable gate arrays (FPGAs)) in order to implement packet broker 106. For instance, according to one known approach, packet broker 106 can be implemented using a network router comprising a number of line cards, where each line card includes an ASIC or FPGA-based packet processor. When the router receives replicated traffic from taps 102, the router processes the traffic using the packet processors based on rules that are programmed into hardware memory tables (e.g., content-addressable memory (CAM) tables) resident on the packet processors and/or line cards. The router then forwards the processed traffic onward to probes/tools 108 for analysis.
While this hardware-based approach for implementing packet broker 106 has certain benefits (e.g., it can process traffic with minimal latency and jitter), it also suffers from several drawbacks. First, the scalability of visibility network 100—in other words, its ability to process increasing volumes of traffic from core network 104—is necessarily constrained by the hardware capabilities of packet broker 106. For example, if packet broker 106 is implemented using a chassis-based router that supports up to X line cards, packet broker 106 cannot scale to support traffic volumes that exceed the capabilities of those X line cards. If such scaling is required, the entire router must be replaced with another router that supports more, or higher capability, line card hardware.
Second, since hardware-based packet brokers perform packet processing based on rules that are programmed into hardware memory tables, these packet brokers are generally limited to executing packet processing operations that conform to the semantics of such rules (i.e., attempt to match one or more header fields of an incoming packet and then perform a specified action if a match is made). While these operations can be chained by passing the output of one packet processor/line card to another, the order of the chaining is fixed in hardware. This rigid processing paradigm is problematic if more flexible, complex, and dynamic packet processing operations are desired.
Third, implementing feature changes or additions to a hardware-based packet broker can be costly and time-consuming due to the need to design and validate such changes at the hardware level. This, in turn, makes it more difficult to quickly iterate the packet broker in response to evolving customer needs/requirements and increases the cost of the device for those customers.